Method of reflecting on another device a change to a browser cache on a handheld electronic device, and assocaited device

ABSTRACT

An improved handheld electronic device includes an Application Programming Interface (API) that generates various notifications in certain circumstances. The handheld electronic device provides an improved method of employing the notifications to enable another device to reflect a change to a browser cache on the handheld electronic device.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of application Ser. No. 11/414,785filed on Apr. 28, 2006, the contents of which are hereby incorporatedherein by reference.

BACKGROUND

1. Technical Field

The disclosed and claimed concept relates generally to handheldelectronic devices and, more particularly, to a method of reflecting onanother device a change to a browser cache on a handheld electronicdevice.

2. Description of the Related Art

Numerous types of handheld electronic devices are known. Examples ofhandheld electronic devices include, for instance, personal dataassistants (PDAs), handheld computers, two-way pagers, cellulartelephones, and the like. Many handheld electronic devices also featurea wireless communication capability, although many such handheldelectronic devices are stand-alone devices that are functional withoutcommunication with other devices.

Some handheld electronic devices that are sold with certain softwareresident thereon and are configured to allow additional softwaredeveloped by third parties to be installed and executed on theelectronic handheld device. In order to facilitate the use of suchthird-party software, the manufacturer of the device may sell the devicewith original software that is sufficiently versatile to enablecooperation between the original software and third-party software. Suchthird-party software may be provided on the device when originallyprovided to a consumer, or may be added after purchase. While suchhandheld electronic devices and software have been generally effectivefor their intended purposes, such handheld electronic devices have notbeen without limitation.

For instance, the original software provided by a manufacturer may beconfigured to be so versatile as to be somewhat burdensome to use. Forexample, the original software may provide a routine such as anApplication Programming Interface (API) that third-party software canemploy to receive notifications in response to certain events on thehandheld electronic device. Due to the intended versatility of theoriginal software, the original software may provide many morenotifications than are needed or are usable by the third-party software.The processing of so many unnecessary notifications undesirably addsprocessing overhead and consumes both processing and power resources.Moreover, despite their versatility, such APIs may still provide fewerthan all of the functions that might be desirable for use with certainthird-party software. For instance, the API may provide certainnotifications, but such notifications may provide less than all of thedata that would be desirable for proper operation of the third-partysoftware.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the disclosed and claimed concept can beobtained from the following Description when read in conjunction withthe accompanying drawings in which:

FIG. 1 is a schematic depiction of an improved handheld electronicdevice in accordance with the disclosed and claimed concept incommunication with a network;

FIG. 2 is a schematic depiction of a portion of a memory on the handheldelectronic device of FIG. 1;

FIG. 3 is an exemplary flowchart of at least a portion of an improvedmethod that can be performed on the improved handheld electronic deviceof FIG. 1; and

FIG. 4 is an exemplary flowchart of at least a portion of another methodthat can be performed on the improved handheld electronic device of FIG.1.

Similar numerals refer to similar parts throughout the specification.

DESCRIPTION

An improved handheld electronic device 4 is depicted schematically inFIG. 1 as being in communication with a network 8. The exemplary network8 enables communication between it and the handheld electronic device 4via an antenna 10 that is connected through the network 8 with a server12. The exemplary network 8 communicates wirelessly with the handheldelectronic device 4, although it is understood that the network 8 couldhave a wired connection with the handheld electronic device 4 withoutdeparting from the present concept.

The exemplary handheld electronic device 4 comprises an input apparatus16, a processor apparatus 20, and an output apparatus 24. The processorapparatus 20 is configured to process input received from the inputapparatus 16 and to provide output to the output apparatus 24.

The processor apparatus 20 comprises a processor and a memory 28. Whilenot expressly depicted herein, it is understood that the processor couldbe any of a wide variety of processors, such as a microprocessor (μP)that is responsive to input from the input apparatus 16, that providesoutput to the output apparatus 24, and that interfaces with the memory28.

The memory 28 is depicted schematically in FIG. 2. The memory 28 can beany of a variety of types of internal and/or external storage media suchas, without limitation, RAM, ROM, EPROM(s), EEPROM(s), and the like thatprovide a storage register for data such as in the fashion of aninternal storage area of a computer, and can be volatile memory ornonvolatile memory. The memory 28 additionally includes a number ofroutines stored therein that are executable on the processor, as will beset forth below in greater detail. As employed herein the expression “anumber of” and variations thereof shall refer broadly to any nonzeroquantity, including a quantity of one. The routines can be in any of avariety of forms such as, without limitation, software, firmware, andthe like.

The memory 28 comprises a browser cache 32 having a number of files 36stored therein within a directory structure. Each file 36 in the browsercache 32 has a file name 40 and has stored therein, for example, anobject 44, a location from where the object 44 was obtained, such as aUniform Resource Locator (URL) 48, and an expiry date 52 for the object44. Additional relevant information may be stored in each file withoutdeparting from the present concept.

The memory 28 additionally has stored therein an operating system 56, anAPI 60, and a browser routine 64, among other routines as mentionedabove. As is understood in the relevant art, the browser routine 64 isoperable to obtain and process various items such as HyperText MarkupLanguage (HTML) documents. A given HTML document may comprise, forexample, text, and may additionally comprise descriptions of locationswhere additional objects may be obtained and which are to be insertedinto the text. Exemplary objects that are insertable into text wouldinclude images, executable code such as JavaScript, and other objects.If an HTML document that is being processed by the browser routine 64comprises one or more locations, the objects stored at such locationsmust be obtained in one fashion or another for inclusion in the outputthat results from the such processing of the HTML document. Thelocations may, for example, be URLs on a network such as the Internet.

In order to reduce communication bandwidth, such as a bandwidth of thewireless communication enabled between the handheld electronic device 4and the network 8, certain of the needed objects may be stored, i.e.,saved, in the browser cache 32 as objects 44 stored within the files 36.For example, if an HTML document being processed by the browser routine64 comprises a location such as a URL 48 in one of the files 36, and ifthe expiry date 52 of the object 44 in the file 36 has not beenexceeded, the object 44 stored in the file 36 is retrieved from withinthe browser cache 32 and is provided to the browser routine 64 forinclusion in the HTML document. In such a fashion, the amount ofcommunication traffic between handheld electronic device 4 and thenetwork 8 can be reduced.

One exemplary implementation of such a browser cache 32 on the handheldelectronic device 4 would additionally include storing on the server 12or otherwise making available to the server 12 a mirror of the browsercache 32. For example, if the network 8 receives a request from thebrowser routine 64 for a particular HTML document that may be obtainablefrom the network 8, the server 12 may analyze the obtained HTML documentand determine whether or not it includes one or more URLs from which maybe obtained objects that should be included in the HTML document. Theserver 12 may determine from its mirror of the browser cache 32 whetheror not the object which is available at a given URL might already bestored in the browser cache 32. If the object is not already stored inthe browser cache 32, the server 12 will request the object from the URLand will send the object to the handheld electronic device 4, typicallyin conjunction with the sending of the HTML document from the server 12to the handheld electronic device 4. On the other hand, if the objectfrom the indicated URL is already available in an unexpired condition inthe browser cache 32, the object is not at that time requested from theURL. In accordance with the disclosed and claimed concept, the mirror ofthe browser cache 32 is advantageously updated whenever the browsercache 32 changes.

Whenever a browser session is initiated, a data table 68, such as isdepicted generally in FIG. 2, is generated and is stored in the memory28. The data table 68 includes a number of first objects 72 and a numberof second objects 76 stored therein. Each first object 72 comprises afile name 40, which is the file name 40 of a file 36 in the browsercache 32. Each first object 72 has associated therewith a second object76 that comprises the location, i.e., the URL 48 in the present example,of the same file 36. In the depicted exemplary implementation, the filenames 40 are each stored in the first objects 72 as a hash of the filename 40 in order to reduce storage requirements and to facilitateprocessing.

After the data table 68 has been created, a hash of each URL 48 in thesecond objects 76 is provided to the server 12 to create on the server12 the mirror of the browser cache 32. It may additionally be desirableto provide, in conjunction with each hash of a URL 48, the expiry date52 of the object 44 that was obtained from the same URL 48, as is storedin one of the files 36.

Whenever the contents of the browser cache 32 undergo a change, thechange is advantageously communicated to the server 12 so that themirror on the server 12 of the browser cache 32 can be updated in orderto enable the mirror of the browser cache 32 to accurately reflect thecontents of the browser cache 32 on the handheld electronic device 4. Inresponse to a change in the browser cache 32, the API 60 is configuredto provide to the browser routine 64 the name of the file 36 in thebrowser cache 32 that has undergone the change. The API 60 also providesa notification of the type of change undergone by the file 36 of whichthe file name 40 has just been provided. The various notificationsinclude a CREATE notification, an UPDATE notification, a DELETEnotification, and a RENAME notification indicating that a particularfile has been created, updated, deleted, or renamed, respectively. Inthe case of a RENAME notification, typically two file names 40 areprovided, i.e., the initial file name 40 of the file 36, as well as anew name for the same file 36.

It is noted, however, that merely providing the file name 40 of the file36 that has undergone a change does not itself provide the URL 48 of thesame file 36, and such URL 48 cannot be obtained directly from theoperating system 56 or the API 60. The browser routine 64 isadvantageously configured to obtain in other fashions the particular URL48 of the file 36 in the browser cache 32 that has undergone the change.

FIG. 3 generally depicts an exemplary flowchart depicting certainaspects of the way in which the server 12 is able to have asubstantially continuously updated mirror of the browser cache 32 thatis stored on the handheld electronic device 4. As indicated above, uponinitiation of a browser session by the browser routine 64, the datatable 68 is generated, as at 104. At least a portion of the data table68 is then supplied, as at 108, to the server 12. As indicated above,typically what is supplied to the server 12 is a hash of each URL 48stored in the second objects 76, along with the corresponding expirydate 52.

The browser routine 64 receives from the API 60 a notification, as at112, that a certain file 36 has undergone a change. Specifically, thefile name 40 of the file 36 that has undergone the change, as well as anotification type are provided to the browser routine 64. As indicatedabove, the four exemplary types of notifications are CREATE, UPDATE,DELETE, and RENAME.

It is then determined, as at 116, whether the notification was a CREATEnotification. If not, it is then determined, as at 120, whether thenotification was a DELETE notification or an UPDATE notification. Ifnot, the notification is ignored, as at 124. However, if it wasdetermined at 120 that the notification was either DELETE or UPDATE, thebrowser routine 64 obtains, as at 128, from the data table 68 the URL 48that is associated with the received file name 40. More specifically,the data table 68 is consulted to identify the first object 72 which hasstored therein a file name 40 that is the same as the received file name40. The second object 76 associated therewith is consulted to obtain theURL 48 stored therein. The URL 48 and other appropriate data are thensupplied, as at 132, to the server 12. The data table 68 is thenupdated, as at 136, to reflect the change that was notified at 112,assuming that the notification was not ignored at 124.

With more particular regard to the additional data that can be supplied,as at 132, to the server, it is noted that a notification which is aDELETE notification will generally result in supplying to the server 12a hash of the URL 48 of the deleted file 36, along with a notificationthat the change was a DELETE. The server 32 will previously have storedin its mirror of the browser cache 32 a hash of the URL 48 in the file36 that is being deleted. Upon receiving the update transmission, as at132, the server will delete from its mirror of the browser cache 32 thehash of the URL 48 of the deleted file 36.

However, if the notification received at 112 was an UPDATE notification,updated data such as an updated expiry date 52 typically will besupplied, as at 132, to the server 12. Such updated data can be obtainedin any of a variety of ways. Such updated data can even be obtained fromthe server 12.

For instance, the browser routine 64 may make a request of the server 12for a specific HTML document. After receiving the request, the serverwill obtain, such as from the network 8, the requested HTML document.The obtained HTML document may comprise one or more URLs, and the server12 may determine from its mirror 12 of the browser cache 32 that theobject available at a particular indicated URL is already stored on thehandheld electronic device 4 as an object 44 in the browser cache 32.However, the server 12 may also determine that the expiry date 52 of theobject 44 has been exceeded, i.e., the object 44 has expired. In thisregard, the browser cache 32 may be configured to delete files 36 whenthe expiry date 52 of the object 44 stored therein has been exceeded. Onthe other hand, however, the browser cache 32 may be configured suchthat the file 36 having stored therein an exceeded expiry date 52 is notnecessarily deleted, but the object 44 stored therein is updated ifrequested after expiration of the expiry date 52.

The server 12 might make the determination that the expiry date 52 ofthe object 44 has been exceeded by first creating a hash of the URLcontained within the obtained HTML document. The server 12 will thenidentifying in its mirror of the browser cache 32 the matching URL hash,and determining whether the expiry date 52 that is associated with theidentified matching URL hash has been exceeded.

If the server 12 determines that the expiry date 52 of an object 44stored in the browser cache 32 has been exceeded, the server 12 may makea new request of the object from the URL. A header of the request mayinclude an instruction to the URL that it provide the object stored atthe URL only if the object has changed since being stored in the browsercache 32. If it turns out that the object is not changed, the URL maysimply return to the server 12 an updated expiry date.

The updated expiry date will then be transmitted to the handheldelectronic device 4, and the operating system 56 will store the receivedexpiry date as an updated expiry date 52 in the corresponding file 40.Such an update will cause the API 60 to generate an UPDATE notificationwhich will be received by the browser routine 64, as at 112. As such,when at 132 the browser routine 64 supplies to the server 12 the URL 48and appropriate additional data, part of the additional data will be theupdated expiry date 52 that has already been stored in the file 36within the browser cache 32.

If the URL returns to the server 12 a different object than is stored inthe browser cache 32, the same URL will likely additionally provide anupdated expiry date. The server then would transmit to the handheldelectronic device the updated object and updated expiry date, and thesewould both be saved in the file 36, with the API 60 generating an UPDATEnotification at 112, and with the updated expiry date 52 being supplied,as at 132 to the server 12.

If at 116 it is determined that the notification was a CREATEnotification, processing continues to 144 where the browser routine 64requests from the operating system 56 the name of a file 36 thatcomprises a URL 48 which was the subject of a recent request by thebrowser routine 64. That is, during a browsing session the browserroutine 64 makes a number of browser requests of the server 12. The factthat a particular URL request was made by the browser routine 64 doesnot indicate whether or not a file 36 having the particular URL storedtherein was recently added to the browser cache 32 since it is possiblethat the object 44 which would otherwise be available at the URL on thenetwork was already stored in the browser cache 32. However, the browserroutine 64 maintains a list of recent URL requests. As such, at 144 thebrowser routine 64 requests of the operating system 56 the name of afile 36 having a particular URL 48 stored therein. The particular URL 48typically will be the URL that was the subject of the most recent URLrequest by the browser routine 64.

In response to the request at 144, the operating system 56 may return afile name 40 or may return nothing. It is then determined, as at 148,whether the returned file name 40, if any, and the file name 40 that wasgenerated as part of a notification at 112 are the same. If they are notthe same, or if no file name was returned in response to the request at144 regarding a particular URL, processing returns to 144 whereadditional requests are made for additional URLs that were the subjectof recent URL requests. In this regard, the URLs employed in therequests at 144 typically will be made in reverse chronological order,i.e., the most recent URL will be the subject of the first request at144, and if the result at 148 is “no”, a successive request at 144 willbe made with respect to the URL that was next most recently requested bythe browser routine 64, and so forth.

In response to one of the requests at 144, the operating system 56 willreturn a file name 40 that matches the file name 40 that was generatedas part of the notification at 112. In such a circumstance, a hash ofthe URL that was the subject of the successful request is supplied, asat 132, to the server 12. The data table 68 is then updated, as at 136.

As a general matter, the API 60 is capable of generating numerousnotifications that may be in excess of what is necessarily or desirablyhandled by the routines on the handheld electronic device 4. Forinstance, the API 60 may generate numerous notifications in response toa single event. By way of example, it is noted that an updatingoperation on the handheld electronic device 4 may generate five separatenotifications as follows:

1) the device may create a new file, thus resulting in a CREATEnotification;

2) the device may update the new file by writing into the new file thecontents of an old file, thus generating an UPDATE notification;

3) the device may append any changes, i.e., edit, the new file, thusresulting in an UPDATE notification;

4) the device may delete the old file, thus resulting in a DELETEnotification; and

5) the device may rename the new file to have the name of the old fileand to have the attributes of the old file, thus resulting in a RENAMEnotification.

In essence, the only meaningful change to the browser cache 32 was theupdating of the old file, but the way in which the updating occurredresulted in the generation of five notifications, only one of which isparticularly meaningful, such as to the browser routine 64. On the otherhand, a routine other than the browser routine 64 might find more thanone of the five notifications to be useful or relevant.

In accordance with the disclosed and claimed concept, the notificationsgenerated by the API 60 are advantageously subjected to one or morepredetermined criteria or algorithms to determine whether or not one ormore of the notifications can be ignored. It is noted that the variouspredetermined criteria, i.e., algorithms, likely will be specific to agiven routine on the handheld electronic device 4. That is, what may bean unnecessary or irrelevant notification to one routine might berelevant or desirably noted by another routine.

The browser routine 64 is provided herein as an exemplary routine towhich certain notifications generated by the API 60 may desirably beignored. It is reiterated that certain of the algorithms may be usablein conjunction with other routines than the browser routine 64, and thatother algorithms may be unusable with routines other than the browserroutine 64. Also, other routines may have other predetermined criteriaor algorithms for use in determining whether certain of thenotifications can be ignored by the routines.

One of the predetermined criteria, i.e., one algorithm, is to determinewhether or not a notification relates to a particular type of file. Forinstance, a certain routine may find relevant only those notificationsthat relate to a file having a suffix “.txt”. As is mentioned above, theAPI 60 may generate a number of notifications that each comprise thetype of notification, i.e., CREATE, UPDATE, DELETE, or RENAME, as wellas the file name 40 of a file 36 that was the subject of thenotification. If the particular routine finds relevant only thoseparticular notifications that relate to a “.txt” file, any notificationthat relates to a file that is of a type other than a “.txt” file willbe ignored.

However, a RENAME notification from a file type that the particularroutine does not consider relevant into a file name that the routinedoes consider to be relevant will be ignored and instead treated as aCREATE notification of the file name that the routine considers to berelevant. For instance, a RENAME notification of a file 36 fromfilename.tmp to filename.txt will be treated as a CREATE notification offilename.txt. Similarly, a RENAME notification from a file type that theparticular routine considers to be relevant into a file name that theroutine does not consider to be relevant will be ignored and insteadtreated as a DELETE notification of the file name that the routineconsiders to be relevant.

It is noted that ignoring a notification can occur in two fashions. Inthe first fashion, ignoring a notification can simply mean paying noattention to the notification, with no subsequent action. The otherfashion of ignoring a notification can occur by paying no attention tothe notification that was received, and rather treating the notificationas a different notification. The different notification can be of adifferent type and/or can be as to a different file.

Notifications typically are received from the API 60 as a sequence,i.e., a plurality of notifications are sequentially received from theAPI 60. The exemplary browser routine 64 may initiate analysis of thenotifications, i.e., for the purpose of potentially ignoring certain ofthe notifications, in response to any of a variety of events. Forinstance, the browser routine 64 might employ a timer which is resetupon each receipt of a notification. The timer may be set to aparticular period of time, i.e., a period of two seconds, or anotherappropriate time period. If the timer expires without detecting anothernotification from the API 60, the analysis of the series ofnotifications may be initiated. On the other hand, notifications may beidentified as being in discrete “bunches” which are analyzed together.Other triggering events can be envisioned.

It is noted, however, that an analysis of a relatively greater number ofnotifications will have a more appropriate result than an analysis of arelatively lesser number of notifications. This is due, at least inpart, to the nature of the analysis. As a general matter, eachnotification is analyzed as being a “current” notification and isanalyzed in the context of a “following” notification in the sequence.That is, notifications are analyzed in pairs. In the examples set forthherein, the “following” notification is a sequentially next notificationimmediately following the “current” notification, but it is noted thatthe “following” notification could, in appropriate circumstances, besequentially later than the immediately next notification after the“current” notification.

An exemplary set of criteria, i.e., algorithms, are set forth in theaccompanying Table 1 below:

TABLE 1 “Following” Notification RENAME from CREATE file UPDATE fileDELETE file “filename2.txt” to “filename1.txt” “filename1.txt”“filename1.txt” “filename1.txt” “Current” CREATE file Ignore the CREATEIgnore the Keep both Keep both CREATE Notification “filename1.txt”notification of UPDATE CREATE and and RENAME “filename1.txt”notification DELETE notifications notifications UPDATE file Ignore theCREATE Ignore the Keep both Keep both UPDATE “filename1.txt”notification of UPDATE UPDATE and and RENAME “filename1.txt”notification DELETE notifications notifications DELETE file If thenotification before Keep both Ignore one Replace these 2 “filename1.txt”the DELETE was a DELETE and DELETE notifications with: CREATE or UPDATE,UPDATE notification DELETE filename2.txt then, ignore this notificationsand UPDATE DELETE and CREATE filename1.txt of “filename1.txt”.Otherwise, replace these 2 notifications with an UPDATE notification for“filename1.txt”. RENAME from Keep both RENAME Keep both Keep both Ignoreone RENAME “filename2.txt” and CREATE RENAME and RENAME and notificationto notifications UPDATE DELETE “filename1.txt” notificationsnotifications

As can be seen from Table 1, if either a CREATE notifications or anUPDATE notification (as a “current” notification) is followed by eithera CREATE notification or an UPDATE notification (as a “following”notification) as to the same file, the “following” notification isignored. For other routines, i.e., other embodiments, the algorithmmight be to ignore either the “current” notification or the “following”notification, and to treat the non-ignored notification as an UPDATEnotification.

As can further be seen from Table 1, if either a CREATE notification oran UPDATE notification is followed by either a DELETE notification or aRENAME notification that indicates a deletion of the same file or arenaming of another file to the same file, both notifications may bekept, i.e., not ignored. This may be based, at least in part, upon theunlikelihood of detecting from the API 60 such a pair of notifications.Table 1 thus suggests that if such an unlikely pair of notifications isdetected, the notifications are not ignored. As an alternative, anotherroutine might choose to ignore both notifications in such acircumstance.

If two sequentially consecutive notifications are precisely the same,i.e., of the same nature and as to the same file, another algorithmmight be to ignore one of the two notifications. With other routines,however, possibly neither notification is ignored due to theunlikeliness of receiving such a pair of notifications.

In the circumstance of a DELETE notification followed by a CREATEnotification as to the same file, it is determined whether or not thenotification that preceded the DELETE notification was either a CREATEnotification or an UPDATE notification. If so, the current DELETE andthe following CREATE notifications are ignored. However, if thenotification preceding the DELETE notification was neither a CREATE noran UPDATE notification, the current DELETE notification and thefollowing CREATE notification are ignored and are treated as a singleUPDATE notification as to the same file. For other routines, the sameresult can be obtained when the current DELETE notification is followedby an UPDATE notification rather than the aforementioned CREATEnotification.

As can further be seen from Table 1, if a DELETE notification as to aparticular file is followed by a RENAME notification renaming anotherfile to the name of the particular file, such notifications are replacedwith a DELETE notification as to the another file and an UPDATEnotification as to the particular file. In effect, the two originalnotifications are ignored, and are treated as two differentnotifications. Alternatively, the two notifications could be treated asa DELETE notification as to the another file and a CREATE notificationas to the particular file. The two different notifications can then beanalyzed in the context of the other notifications in the sequence ofnotifications being analyzed in order to possibly ignore one or more ofthese notifications or other notifications in the series.

As can further be seen from Table 1, a RENAME of one file to the name ofanother file which is followed by a CREATE, an UPDATE, or a DELETEnotification as to the another file will result in neither notificationbeing ignored. In other embodiments, however, one or more of suchnotifications could potentially be ignored, depending upon the needs ofthe routine.

As an example, a sequence of notifications to be analyzed may be asfollows:

CREATE filename.tmp UPDATE filename.tmp UPDATE filename.tmp UPDATEfilename.tmp UPDATE filename.txt DELETE filename.txt RENAME filename.tmpto filename.txt UPDATE filename.txt.

As a first step we may ignore the notifications for files of a typeabout which the browser routine 64 is not concerned. For example, allnotifications relating to a file name other than a “.txt” file will beignored. However, the RENAME notification from filename.tmp tofilename.txt will be treated as a CREATE notification of filename.txt.This leaves the following:

UPDATE filename.txt DELETE filename.txt CREATE filename.txt UPDATEfilename.txt.

When the first two notifications are considered as a “current” and a“following” notification, Table 1 indicates that an UPDATE notificationfollowed by a DELETE notification as to the same file results in bothnotifications being kept. If the aforementioned DELETE notification isnow considered a “current” notification and is analyzed in the contextof the subsequent CREATE notification being a “following” notification,Table 1 indicates' that a DELETE notification that is preceded by anUPDATE notification and followed by a CREATE notification as to the samefile name, will result in the DELETE and the following CREATEnotifications both being ignored.

In the circumstance of a “following” notification being ignored, thenext “current” notification to be analyzed will be the most immediatelypreceding notification that has not yet been ignored. Thus, the firstUPDATE notification will again be considered as a “current”notification, and will be considered to be followed by the second UPDATEnotification. Table 1 indicates that an UPDATE notification followed byanother UPDATE notification as to the same file will result in thesecond UPDATE notification being ignored.

In the context of the exemplary browser routine 64, therefore, seven ofthe eight notifications in the exemplary notification sequence abovewere ignored. As a result, the method indicated for example by theflowchart in FIG. 3 would need to be executed only once, i.e., for thesole remaining UPDATE notification, rather than executing the sameroutine eight separate times. This advantageously saves executing andpower resources.

Such a method is depicted generally in the exemplary flowchart of FIG.4. For instance, the browser routine 64 listens, as at 204, fornotifications from the API 60. It is determined, as at 208, whether ornot a notification was received. If a notification was received, thetimer is reset, as at 212, and processing returns to 204 where thebrowser routine 64 listens for further notifications. If at 208 it isdetermined that no notification was received in the preceding listeningoperation at 204, it is then determined, as at 216, whether or not thetimer has expired. If not, processing returns to 204 where furtherlistening occurs.

In this regard, it can be understood that the exemplary steps 204, 208,212, and 216 form a loop that is repeated at certain intervals, perhapsas often as the processor can execute the loop. Once the timer hasexpired without having received an additional notification, processingcontinues to 220 whether it is determined whether or not any of thenotifications meet any of the predetermined criteria, i.e., the criteriathat are predetermined for the routine performing the listening at 204or for which the notifications are being detected. If no notificationsmeet the predetermined criteria, the notifications are acted upon, as at224. Such notifications may be acted upon by being stored, by initiatingother processing, or in other fashions.

If, however, at 220 it is determined that some of the notifications meetone or more of the predetermined criteria, processing continues at 228where certain of the notifications are ignored and, as appropriate, maybe treated as being different notifications. Processing thereaftercontinues at 224 where the remaining notifications are acted upon.

With further regard to the operations at 220, it is understood that anyof a variety of criteria, i.e., algorithms, can be employed dependingupon the needs of the particular routine in question. As such,algorithms in addition to those set forth herein can be employed withoutdeparting from the present concept.

While specific embodiments of the disclosed and claimed concept havebeen described in detail, it will be appreciated by those skilled in theart that various modifications and alternatives to those details couldbe developed in light of the overall teachings of the disclosure.Accordingly, the particular arrangements disclosed are meant to beillustrative only and not limiting as to the scope of the disclosed andclaimed concept which is to be given the full breadth of the claimsappended and any and all equivalents thereof.

1. At a server of mobile communications devices, a method of servicingrequests for HTML documents, said HTML documents containing a pluralityof HTML objects, from mobile communications devices, said methodcomprising: upon initiation of a browser session at a given mobilecommunications device served by said server, receiving at least aportion of a copy of a mobile data table stored on said given mobilecommunications device, said mobile data table comprising (i) a filenameof an HTML object, (ii) an associated URL of a location from which saidassociated HTML object was obtained, and (iii) an associated expirydate, so as to indicate the contents of a browser cache of HTML objectsat said mobile communications device; reflecting said mobile data tablein a server data table for said given mobile communications device;thereafter, receiving updates from said given mobile communicationsdevice of changes to said browser cache such that said server data tableis maintained as a mirror of said mobile data table; upon receiving arequest for an HTML document from said given mobile communicationsdevice, determining from said server data table whether HTML objectscontained in said requested HTML document are present in said browsercache; and sending a copy of a particular HTML object to said givenmobile communications device when said determining determines that saidparticular HTML object is not present in said browser cache; and sendingan update to said given mobile communications device when saiddetermining determines that said particular HTML object is present insaid browser cache in an expired state.
 2. The method of claim 1 whereinsaid sending an update to said given mobile communications devicecomprises requesting a new copy of said particular HTML object from alocation indicated by an associated URL stored in said server data tablefor said HTML object only if said particular HTML object has changedsince a given time wherein said given time is indicated by an associatedexpiry date of said particular HTML object stored in said server datatable.
 3. The method of claim 2 further comprising sending an updatedexpiry date of said particular HTML object to said given mobile datacommunications device when said HTML object has not changed.
 4. Themethod of claim 2 further comprising sending (i) said new copy of saidparticular HTML object to said given mobile data communications devicewhen said HTML object has changed, and (ii) an expiry date of said newHTML object.
 5. The method of claim 1 wherein said receiving updatescomprises receiving from said given mobile communications device (i) aCREATE notification and (ii) at least a representation of a URLassociated with said created HTML object.
 6. The method of claim 1wherein said receiving updates comprises receiving from said givenmobile communications device (i) a DELETE notification for a particularHTML object and (ii) at least a representation of a URL associated withsaid deleted HTML object.
 7. The method of claim 1 wherein saidreceiving updates comprises receiving from said given mobilecommunications device (i) a RENAME notification for a particular HTMLobject and (ii) an indicator of the new name of said renamed particularHTML object.
 8. A method of processing HTML documents at a mobilecommunications device during a browser session, said browser sessionincluding communication with a server servicing requests from saidmobile communications device for HTML documents, said method comprising:maintaining a browser cache of HTML documents at said mobilecommunications device; maintaining a mobile data table at said mobilecommunications device comprising a plurality of records, each recordcomprising (i) a filename of an HTML object in said browser cache, (ii)an associated URL of a location from which said associated HTML objectwas obtained, and (iii) an associated expiry date; upon initiation ofsaid browser session providing at least a portion of a copy of saidmobile data table to said server; detecting that a particular HTMLobject in said browser cache has undergone a change; responsive to saiddetecting, sending an update to said server, said update comprising afilename of said particular HTML object and an indicator of the natureof said change, whereby said mobile data table is mirrored at saidserver.
 9. The method of claim 8 wherein said detecting comprisesdetecting that said particular HTML object has been deleted and whereinsaid method further comprises deleting the mobile data table recordassociated with said HTML object.
 10. The method of claim 9 wherein saidsending an update to said server comprises sending at least arepresentation of a URL associated with said deleted HTML object and aDELETE indicator.
 11. The method of claim 10 wherein said representationof a URL is a hash representation of said URL.
 12. The method of claim 8wherein said detecting comprises detecting that said particular HTMLobject has been updated and wherein said method further comprisesupdating the mobile data table record associated with said HTML objectwith an updated expiry date.
 13. The method of claim 12 wherein saidsending an update to said server comprises sending at least arepresentation of a URL associated with said updated HTML object, anUPDATE indicator and an expiry date.
 14. The method of claim 12 whereinsaid detecting that said particular HTML object has been updatedcomprises receiving an UPDATE notification from said server.
 15. Themethod of claim 13 wherein said representation of a URL is a hashrepresentation of said URL.
 16. The method of claim 8 wherein saiddetecting comprises detecting that said particular HTML object has beenrenamed and wherein said method further comprises updating the mobiledata table record associated with said HTML object with a new name. 17.The method of claim 16 wherein said sending an update to said servercomprises sending at least a representation of a URL associated withsaid renamed HTML object and a RENAME indicator and an indicator. 18.The method of claim 17 wherein said representation of a URL is a hashrepresentation of said URL.
 19. The method of claim 8 further comprisingdetecting that a new HTML object has been added to said browser cacheand creating a new record in said mobile data table associated with saidnew HTML object.
 20. The method of claim 19 further comprising providingat least a portion of said new record to said server, said new record atleast including a representation of a URL associated with said new HTMLobject.